1. Field of Invention
This invention relates in general to software applications, and more particularly to tracking software revisions.
2. Description of Background
Open source development using multiple licenses has made managing source code a serious challenge for corporations. As a result of the proliferation of projects based on open source code, corporations must support customers on unlimited, and somewhat unknown versions of software. Answering the question: “What driver do I need?” and comparing this to: “What driver am I running?” Needless to say, it has become a daunting and frustrating task to determine the necessary driver.
This issue was not present in proprietary operating systems, because vendors could control installation tools and use release numbers to track the version of the source code running on any given system. Since open source developers frequently do not update the release field (even if it is present) the current tools available for managing code levels do not work in this environment.
Specifically, existing code management tools such as a concurrent version system (CVS) tool fail to provide sufficient granularity when tagging files to assist with this problem. For example, today, CVS provides keyword substitution for elements such as:
$Revision: 1.5$
$Id:hello.c. v 1.1 2001/06/01 03:21:13 jrandom Exp qsmith $
$R Csfile:hellow.c, v $
This source code informs a user that the revision number is 1.5 of the driver. However, in Linux, frequently there is a 1.5 version on a developer's A box, that's different from the 1.5 version of the code on developer's B box. The 1.5 shows you some general common origin, but does not uniquely identify the code. The current tools available for discovering what is running on an existing system are to obtain the output from a modprobe-v program.
Thus, there is a need for a source code management system to calculate the checksum of the source file itself and allow the user to tag the file for display by programs such as the modprobe.